Skip to content

[WIP] Forbid object lifetime changing pointer casts #136776

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

BoxyUwU
Copy link
Member

@BoxyUwU BoxyUwU commented Feb 9, 2025

Fixes #136702

r? @ghost

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Feb 9, 2025
@BoxyUwU
Copy link
Member Author

BoxyUwU commented Feb 9, 2025

@bors try

bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 9, 2025
…, r=<try>

[WIP] Forbid object lifetime changing pointer casts

Fixes rust-lang#136702

r? `@ghost`
@bors
Copy link
Collaborator

bors commented Feb 9, 2025

⌛ Trying commit d5ebeac with merge 44f3504...

@bors
Copy link
Collaborator

bors commented Feb 9, 2025

☀️ Try build successful - checks-actions
Build commit: 44f3504 (44f3504e96c944ae54fc72b5f5008f53f7eda001)

@BoxyUwU
Copy link
Member Author

BoxyUwU commented Feb 9, 2025

@craterbot check

@craterbot
Copy link
Collaborator

👌 Experiment pr-136776 created and queued.
🤖 Automatically detected try build 44f3504
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 9, 2025
@craterbot
Copy link
Collaborator

🚧 Experiment pr-136776 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot
Copy link
Collaborator

🎉 Experiment pr-136776 is completed!
📊 169 regressed and 4 fixed (580506 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

@craterbot craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Feb 11, 2025
@RalfJung
Copy link
Member

RalfJung commented Feb 11, 2025

Most of these are on github; in terms of crates.io regressions all we have is:

  • may
  • a bunch of crates using metrics, see e.g. this (for metrics-0.23) or this (for metrics-0.24, the latest version)

Overall, 142 regressions are caused by metrics and 14 by may; if we ca get fixed versions of those crates out that seems to mostly cover it.

EDIT: Ah, there's also cogo.

@traviscross traviscross added the I-lang-nominated Nominated for discussion during a lang team meeting. label Feb 12, 2025
@traviscross
Copy link
Contributor

We discussed this in the lang triage call today. We wanted to think more about it, so we're leaving it nominated to discuss again.

@tmandry
Copy link
Member

tmandry commented Feb 19, 2025

@BoxyUwU Do you think it would be possible to implement this as an FCW? We talked about this in lang triage today and would prefer to start with that if we can. If it's not feasible, a hard error can also work (I would say though that we should upstream PRs to any crates we break).

Another small thing I noticed is that the error message links to the Nomicon section on variance, but it would be ideal to link to a tracking issue or something describing this issue in particular.

@traviscross
Copy link
Contributor

traviscross commented Feb 19, 2025

To add on to what tmandry, said, in our discussions we did feel that the approach taken in this PR is generally the right way forward, and we're happy to see this progress so as to help clear the way for arbitrary_self_types and derive_coerce_pointee.

cc @rust-lang/lang

@BoxyUwU
Copy link
Member Author

BoxyUwU commented Feb 26, 2025

@tmandry I do expect it to be possible to FCW this. We can likely do something hacky around to fully emulate the fix (but as a lint), but if that doesn't work out all the regression we found were relatively "simple" cases that can probably be taken advantage of (if need be) to lint a subset of the actual cases we'd break with this PR

edit: see compiler-errors' comment, I'm not so convinced this will be possible to FCW anymore and will likely investigate improving the diagnostics here. I've already filed PRs to the affected crates to migrate them over to a transmute to avoid the breakage if this lands

@compiler-errors
Copy link
Member

I was thinking earlier that it may be possible to implement a lint to detect, but it seems to me that MIR borrowck is not equipped to implement such a lint.

Specifically, it seems near impossible to answer whether a region outlives constraint (like, 'a: 'b) would not hold in a way that doesn't actually commit to that constraint, at least not without tons of false positives based on how NLL computes lower bounds for all of the regions it deals with in the MIR.

To fix this would require some significant engineering effort to refactor how NLL processes its region graph to make it easier to clone and reprocess with new constraints.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Mar 4, 2025
…uto_to_object-hard-error, r=oli-obk

Make `ptr_cast_add_auto_to_object` lint into hard error

In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds.  This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting.

We considered just making this a hard error, but opted against it at that time due to breakage found by crater.  This breakage was mostly due to the `anymap` crate which has been a persistent problem for us.

It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`.  So let's see about making a hard error of this.

r? ghost

cc `@adetaylor` `@Darksonn` `@BoxyUwU` `@RalfJung` `@compiler-errors` `@oli-obk` `@WaffleLapkin`

Related:

- rust-lang#135881
- rust-lang#136702
- rust-lang#136776

Tracking:

- rust-lang#127323
- rust-lang#44874
- rust-lang#123430
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Mar 5, 2025
…uto_to_object-hard-error, r=oli-obk

Make `ptr_cast_add_auto_to_object` lint into hard error

In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds.  This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting.

We considered just making this a hard error, but opted against it at that time due to breakage found by crater.  This breakage was mostly due to the `anymap` crate which has been a persistent problem for us.

It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`.  So let's see about making a hard error of this.

r? ghost

cc ``@adetaylor`` ``@Darksonn`` ``@BoxyUwU`` ``@RalfJung`` ``@compiler-errors`` ``@oli-obk`` ``@WaffleLapkin``

Related:

- rust-lang#135881
- rust-lang#136702
- rust-lang#136776

Tracking:

- rust-lang#127323
- rust-lang#44874
- rust-lang#123430
jieyouxu added a commit to jieyouxu/rust that referenced this pull request Mar 5, 2025
…uto_to_object-hard-error, r=oli-obk

Make `ptr_cast_add_auto_to_object` lint into hard error

In Rust 1.81, we added a FCW lint (including linting in dependencies) against pointer casts that add an auto trait to dyn bounds.  This was part of work making casts of pointers involving trait objects stricter, and was part of the work needed to restabilize trait upcasting.

We considered just making this a hard error, but opted against it at that time due to breakage found by crater.  This breakage was mostly due to the `anymap` crate which has been a persistent problem for us.

It's now a year later, and the fact that this is not yet a hard error is giving us pause about stabilizing arbitrary self types and `derive(CoercePointee)`.  So let's see about making a hard error of this.

r? ghost

cc ```@adetaylor``` ```@Darksonn``` ```@BoxyUwU``` ```@RalfJung``` ```@compiler-errors``` ```@oli-obk``` ```@WaffleLapkin```

Related:

- rust-lang#135881
- rust-lang#136702
- rust-lang#136776

Tracking:

- rust-lang#127323
- rust-lang#44874
- rust-lang#123430
@traviscross traviscross added the T-types Relevant to the types team, which will review and decide on the PR/issue. label Apr 2, 2025
@BoxyUwU BoxyUwU force-pushed the forbid_object_lifetime_casts branch from d5ebeac to cfa1e3a Compare May 22, 2025 17:48
@BoxyUwU
Copy link
Member Author

BoxyUwU commented May 22, 2025

I've pushed a first attempt at some special cased diagnostics for this breakage, it links to #141402 which could probably do with some work.

@BoxyUwU
Copy link
Member Author

BoxyUwU commented May 22, 2025

Oh another update: the metrics crate which was responsible for the vast majority of regressions has been fixed and had the fix backported to older versions too. I think may was also fixed in a non-major release. So both may and metrics users broken by this should be able to cargo update to be unbroken

@bors
Copy link
Collaborator

bors commented Jul 2, 2025

☔ The latest upstream changes (presumably #143036) made this pull request unmergeable. Please resolve the merge conflicts.

@Darksonn
Copy link
Contributor

It seems to me that all of the things requested in #136776 (comment) have been added.

@rustbot labels +I-lang-nominated -I-lang-radar

@rustbot rustbot added I-lang-nominated Nominated for discussion during a lang team meeting. and removed I-lang-radar Items that are on lang's radar and will need eventual work or consideration. labels Jul 20, 2025
@traviscross traviscross added the P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang label Jul 21, 2025
@traviscross
Copy link
Contributor

We talked about this in the lang meeting today. Let's do it.

Note that we'll want a Reference PR for this.

This is a dual FCP with types.

@rfcbot fcp merge

@rfcbot
Copy link
Collaborator

rfcbot commented Jul 23, 2025

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

Concerns:

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels Jul 23, 2025
@traviscross
Copy link
Contributor

cc @ehuss

@nikomatsakis
Copy link
Contributor

@rfcbot reviewed

1 similar comment
@tmandry
Copy link
Member

tmandry commented Jul 23, 2025

@rfcbot reviewed

@traviscross traviscross added I-lang-radar Items that are on lang's radar and will need eventual work or consideration. and removed I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang labels Jul 23, 2025
@BoxyUwU
Copy link
Member Author

BoxyUwU commented Jul 23, 2025

@rfcbot concern needs FCP proposal

want to actually write up something for the types folks first before they have to look at this

@BoxyUwU
Copy link
Member Author

BoxyUwU commented Jul 23, 2025

Note that we'll want a Reference PR for this.

I will not have time to make such a PR myself and am not particularly interested in writing one either. it seems like the existing state of the reference does not really talk whatsoever about the restrictions on pointer casts let alone about subtle details of region constraints arising from each MIR operation.

I am surprised that this PR would require a reference PR when previous PRs in this area did not, e.g. disallowing casting *const dyn Trait to *const dyn Trait + Send (#136764) did not have a reference PR despite being much less "nuances of borrow checking".

@Darksonn
Copy link
Contributor

If documentation is required to land this, then I am happy to write it.

@BoxyUwU
Copy link
Member Author

BoxyUwU commented Jul 23, 2025

@rfcbot concern can we do a FCW

I want to take a second look at whether a FCW would be possible

@traviscross
Copy link
Contributor

If documentation is required to land this, then I am happy to write it.

Thanks for that.

@traviscross
Copy link
Contributor

traviscross commented Jul 23, 2025

I am surprised that this PR would require a reference PR when previous PRs in this area did not, e.g. disallowing casting *const dyn Trait to *const dyn Trait + Send (#136764) did not have a reference PR despite being much less "nuances of borrow checking".

The relevant change for that went in ahead of the PR, in rust-lang/reference#1622.

  • Both the same trait object metadata, modulo dropping auto traits (*dyn Debug -> *(u16, dyn Debug), *dyn Debug + Send -> *dyn Debug)
    • Note: adding auto traits is only allowed if the principal trait has the auto trait as a super trait (given trait T: Send {}, *dyn T -> *dyn T + Send is valid, but *dyn Debug -> *dyn Debug + Send is not)

You'll notice I put up #136764 the day after merging the Reference PR. I don't recall the specifics, but it probably wasn't a coincidence.

That said, I'm sure you can find cases where we let something through that should have had a Reference PR but did not. We're trying to be better about this. As you may have seen, e.g., in the PR for the release notes of Rust 1.89, in #144097 (comment), I spot-checked how we did about this for that release.

@BoxyUwU
Copy link
Member Author

BoxyUwU commented Jul 23, 2025

I don't see that documentation you linked anywhere in the reference. It's not in the pointer casts section and there's nothing under the big table in the type casts sections that talks about this.

@traviscross
Copy link
Contributor

traviscross commented Jul 23, 2025

I don't see that documentation you linked anywhere in the reference. It's not in the pointer casts section and there's nothing under the big table in the type casts sections that talks about this.

In rust-lang/reference#1732, it was moved to the footnote here:

https://doc.rust-lang.org/1.88.0/reference/expressions/operator-expr.html#footnote-meta-compat

Admittedly that's probably not the best place for it. (Partly it's a rendering issue; we'd prefer for footnotes on tables to appear directly below the table.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. I-lang-radar Items that are on lang's radar and will need eventual work or consideration. proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-lang Relevant to the language team T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

arbitrary_self_types + derive_coerce_pointee allows calling methods whose where clauses are violated